…ked_hash_map

Uses Google FuzzTest in PBT mode (plain bazel test; --config=fuzztest
enables continuous coverage-guided fuzzing). Each test states its
property explicitly in a comment.

chunked_vector (ChunkedVectorPBT):

  VectorModelOracle: drives both chunked_vector<int32_t> and
  std::vector<int32_t> through the same arbitrary sequence of push_back,
  pop_back, pop_back_n, erase_to_end, reserve, sort, and clear. After
  every operation, asserts element-wise equality AND structural
  invariants (size == sum of fragment sizes, capacity == sum of fragment
  capacities, all fragments except the last are completely full). The
  structural check catches bugs that leave the container logically correct
  but physically inconsistent.

  SortedBinarySearch: after sorting a chunked_vector the same way as a
  std::vector, std::lower_bound and std::upper_bound must return the same
  distance-from-begin on both. Exercises the full random-access iterator
  contract (operator+, operator-, operator[], operator<=>); such bugs
  would pass simple forward-iteration tests.

  IndexedAccessMatchesIterator: operator[](i) and *(begin()+i) must
  return the same element for every valid index. Both paths compute the
  same fragment-index / offset math independently, so a miscalculation
  in either shows up here.

  ReverseIterationMatchesReverse: rbegin()/rend() must yield elements in
  the reverse of forward order, exercising the reverse_iterator adapter
  wrapping the random-access iterator.

chunked_hash_map (ChunkedHashMapPBT):

  MapModelOracle: drives both chunked_hash_map<int32_t,int32_t> and
  std::unordered_map through the same insert_or_assign / erase / find
  sequence. After every operation, asserts size equality and that every
  key in the oracle is present in the map with the same value.

  InsertBatchThenIterateAll: inserts a batch of pairs (last write wins)
  and checks that iterating over the map visits exactly the same sorted
  key set as the deduplicated oracle. Targets the growth path where new
  chunked_vector fragments are added to the bucket and value storage.

Adds --config=fuzztest-cov which layers -fprofile-instr-generate and
-fcoverage-mapping on top of --config=fuzztest to collect LLVM source-
level coverage data during a fuzz run.

To generate an HTML coverage report:

  # 1. Run the fuzzer (Ctrl-C after however long you want)
  LLVM_PROFILE_FILE=/tmp/fuzz.profraw \
    bazel run --config=fuzztest-cov //src/v/container/tests:chunked_pbt \
    -- --fuzz=ChunkedVectorPBT.VectorModelOracle

  # 2. Locate the LLVM tools from the Bazel-managed toolchain
  LLVM=$(bazel info output_base)/external/toolchains_llvm++llvm+current_llvm_toolchain/bin

  # 3. Merge the raw profile
  $LLVM/llvm-profdata merge /tmp/fuzz.profraw -o /tmp/fuzz.profdata

  # 4. Generate the HTML report
  #
  #    Bazel compiles some files with absolute sandbox paths that no
  #    longer exist after the build. Use -ignore-filename-regex to skip
  #    those so llvm-cov doesn't choke on missing files. Our src/v/ files
  #    use workspace-relative paths and are readable fine.
  #
  rm -rf /tmp/cov-report
  $LLVM/llvm-cov show \
    bazel-bin/src/v/container/tests/chunked_pbt \
    -instr-profile=/tmp/fuzz.profdata \
    -ignore-filename-regex='\.cache/bazel|/external/|^base64\.c' \
    -format=html \
    -output-dir=/tmp/cov-report

  # 5. Serve and open in a browser
  python3 -m http.server 8080 --directory /tmp/cov-report
  # then open http://<host>:8080